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(54) Disease management method and system 

(57) The Disease Management system and method 
includes a Patient Medical inforniation source (100), a 
Predictive Health Outcome Modeling process (102), a 
process for Intervention of At-risk Patients (103), and a 
source of disease management Modeling Guidelines 
(104). The Patient Medical Infornration source (101) is a 
database containing medical records of patients who 
partidpate in a healthcare provider's program. The Pre- 
dictive Health Outcome Modeling process (102) pro- 
duces a statistical model used to predict whether a 
patient with a particular disease is likely to suffer an 
adverse hearth outcome. The Intervention of At-risk 
Patients process (103) derives a list of at-risk patients 
who have a high risk of suffering an adverse health out- 
come and intervenes in the selected patient's health- 
care treatment to decrease tiie possibility of such an 
adverse hearth outcome. The Predictive Hearth Out- 
come Modelling process (102) 1) receives a sample 
group of patient medical data from tiie Patient Medical 
Information database (100) for a given disease, 2) 
receives pre-determined statistical information for gen- 
erating predictive models, shown as the Modeling 
Guidelines (104), and 3) generates a particular predic- 
tive nfKxlel for a particular disease to determine the 
probability of an adverse health outcome. The Interven- 
tion of At-risk Patients process (103) 1) receives ttie 
predictive model provided by ttie Predictive Healtii Out- 
come Modeling process (102), 2) analyzes ttie individ- 
ual patient specific medical data from the Patient 



Medical Information database (100). and 3) identifies a 
list of current patients that are at-risk of an adverse 
healtii outcome for a particular disease. The Interven- 
tion of At-risk Patients (103) process Inten^enes in the 
treatment process of the patients contained in the 
patient list through contact witti the patient, physician, or 
healtiicare provider, and the process requires externally 
generated Information about treatment regimens for 
given stages of disease progression, as well as particu- 
lar interventions. 
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Description 

FIELD OF THE INVENTION 

[CMX)1 ] This Invention relates to electronic oonputational processing techniques in the field of human healthcare and, 
more particularly, to identification of high-risk patients for disease and disease intervention management using various 
electronic computational processing techniques. 

BACKGROUND OF THE INVENTION 

[0002] Diseases or condition can be more effectively and more cost-effectively treated by designing a program to 
maximize compliance with current best medical practices which are also consistent with a given preferred treatment 
regimen and on a case by case basis. Treatment for many types of diseases has moved from episodic, synptomatic 
treatment to disease reduction and prevention. 

[0003] Healthcare costs in general are rising rapidly, and. In many cases, the costs of treating patients is not distrib- 
uted evenly among the total population of patients because it costs more to treat some patients ttian others. This is 
partiy due to some patients not receiving appropriate therapies for their medical condition. This problem has several 
causes, including that some patients do not comply with their prescribed treatment regimens, ttiat some patients do not 
visit their doctors at appropriate times, and. in some cases, that some doctors are not aware tiiat a certain therapy reg- 
imen is more likely to be more effective than their current regimen. 

[0004] If patients are treated in accordance with therapy regimens proven to be effective for a given state of disease 
progression, then the total costs of treating the whole population will decline. If more patients are treated properly, then 
the number of cases which progress to more serious stages of disease, which are more costiy to treat, will he reduced. 

SUMI^ARY OF THE INVENTION 

[0005] The present invention is a computer-implemented system and method for identifying at-risk patients, particu- 
larly those diagnosed witii an identified disease, where the information about patients is extracted from at least one pre- 
existing in at least one database. The system includes a means for processing the patient information in the datat)ase 
based on a predetermined criteria to extract relevant infonmatfon for a group of patients having or who may develop the 
identified disease. The system defines a predictive model including associated rules, by: 

a) processing, based on predetermined aiteria, tiie patient information in the database to extract patient informa- 
tion for a group of patients relating to an identified disease or condition; 

b) defining a predictive model, including: 

i) defining, using the information available in the database, a set of events or data relevant to the identified ds- 
ease or condition; 

ii) converting the extracted patient information and the defined events or data into files conprising event-level 
information; 

iii) defining a time^window for providing a timeframe from which to judge whether specific ones of the defined 
events shoukl be considered in subsequent processing; 

iv) identifying a set of variables as potential predictors; 

v) processing tiie event-level information, using the time-window and the set of variables, to generate an anal- 
ysis file; 

vi) performing statistical analysis on the analysis file to generate the prediction model and a set of rules for use 
in identifying at-risk patients diagnosed with or who may develop the identified disease or condition, said pre- 
diction model and rules being a function of a subset of the set of variables; 

c) applying the prediction model and the rules to the same or new set of event-level information to identify at-risk 
patients for the identified disease or condition, or to identify patients who may be at risk for developing the identified 
disease or condition; 

d) preparing an intervention list from the identified at-risk patients and selecting, for at least one at risk patient, an 
intervention; 

e) distributing or facilitating tiie distribution of the inten^ention to said patient: and optionallyf) recording and tracking 
an intervention result for each at-risk patient based on tiie respective selected inten^ention; and optionally 

g) updating the historical data in at least one database with each inten^ention result con-esponding to said data- 
base: and 
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repeating step b(ii), and 

h) re-applying the prediction model and rules to the event-level information extracted from the data in the updated 
database. 

5 BRIEF DESCRIPTION OF THE DRAWINGS 

[0006] The invention is best understood from the following detailed description when read in connection with ttie 
accompanying drawing, in which: 

10 Figure 1 A Is a high level diagram of the Disease Management System of the present invention 

Figure 1 B is a high level flowchart illusfrating an exemplary overall process of the Disease Management System of 
the present invention. 

Figure 2A is a high level flowchart illustrating the raw patient data acquisition, pre-processing, and database forma- 
tion of the present invention. 

15 Figure 2B is a high-level block diagram Illustrating three exemplary sources of information suitable for use with the 
present invention. 

Figure 3 is a flowchart of an embodiment of the conversion process of the Raw Patient Data Pre-processing proc- 
ess of the present invention. 

Figure 4 is an illustration of an exemplary Data Model as used in the Disease Management database of an enr*od- 
20 iment of tiie present Invention. 

Figure 5 is a diagram illustrating the research datat)ase format for each off the Rx. D R, and HL daims of the records 

contained in the research database of an exemplary embodiment of the present invention. 

Figure 6 is a high level flowchart illustrating the Extraction process and Predictive Modeling process for an identified 

disease of the present invention. 
25 Figure 7A is a diagram illustrating an event level file of one embodiment of the present invention generated for 

depression as the identified disease. 

Figure 7B is a diagram illustrating an event level file of one embodiment of the present invention generated for con- 
gestive heart failure as the identified disease. 

Figure 8 is a diagram illustrating the format of the analysis file of one embodiment of the present invention for an 
30 identified disease. 

Figure 9 is a time-line diagram showing ttie events and prediction window scheme as used in the present invention. 
Figure 1 0A is a time-line diagram wrtiich shows a first exemplary time window scheme suitable fa use in processing 
the data from the event level files shown in Rgure 7A and Figure 7B. 

Figure 1 0B is a time-line diagram which shows a second exenrplary time window scheme suitable for use in 
35 processing the data from the event level files shown in Rgure 7A and Rgure 7B. 

Figure 1 1 is a high level flowchart showing ttie Risk Stratification process of ttie present invention including ttie 
Front End process and the Mining Engine process to generate an intervention list for an identified disease. 
Figure 12 is a high level flow chart showing the Mining Engine of ttie Risk Stratification process of ttie present 
invention. 

40 Figure 13 is a high level diagram of tfie Intervention Management process of ttie present invention. 
DETAILED DESCRIPTION OF THE INVENTION 
General Overview 

45 

[0007] The Disease Management system and method of ttie invention increases ttie number of patients within a given 
population who receive, corrply witti, and correcHy administer appropriate therapies for treating a disease or condition. 
The invention requires identifying preferred treatment regimens for given stages of disease progression. These regi- 
mens may be published medical guidelines or guidelines developed by healtticare professionals for a given type off dis- 

50 ease. These guidelines are called Best Practice Guidelines. 

[0008] The term "disease management" applies to, for example, managed care organization, medical group, 
employer, or government sponsored programs that identify individual patients witti chronic long term conditions ttiat 
may be at risk of expensive hospitalization or other high cost events or adverse hearth outcome. Disease management 
services are defined by a research area in conjunction witii product development managers who serve as disease sub- 

55 ject matter experts. 

[0009] Disease management services are offered to clients (participating managed care organizations (MCOs) or 
other types off subscrtoers) for ttie purposes of early intervention at specific disease states to irrprove future disease 
outcomes. An individuars medical, clinical and administrative medical history information Is provided from, for exanple. 



3 



EP 0 9117 078 Al 
third party processors to the disease management system. 

[0010] TTiis specification primarily describes use of the Disease Management system of the present Invention with 
regard to the healthcare field in which healthcare providers are the primary clients of the system, and information about 
the patients of these heafthcare providers are provided to a datat>ase for the practice of the invention. However, it is con- 
5 templated that other embodiments of the invention include other types of clients, such as employers, govo-nment agen- 
cies, insurance providers, or other users who are interested in disease management or the thriftiness of a given 
population of individuals. Similarly, the information provided to the datat}ase of the Disease Management system could 
be expanded to include demographic data, socialization, geographic data, family history, or other infonnation about an 
individual. 

10 [001 1 ] A basic dsease n^anagement system will look at one disease or condition. But multiple diseases or conditions 
can be factored into a single analysis and thereby develop a risk profile based on multiple factors and multiple diseases 
or conditions. In essence, the approach is to view each disease or condition as a module which can be cross-referenced 
like the fields of a relational data base. That permits the analyst to draw on more than one disease or condition in devel- 
oping a risk factor for a given patient population. 

IS [0012] Referring to Figure 1 A, the high level diagram of the cfisease management process off the present invention 
includes a Patient Medical Intbrnration source 100, a Predictive Health Outcome Modeling process 102. a process for 
Intervention of At-risk Patients 103. a source of disease management Modeling Guidelines 104. and a source off Inter- 
vention and Medical Guidelines 105. The process for Intervention of At-Risk Patients 103 has two parts: a Risk Strati- 
fication process 140 and an Intervention Management process 160. The Patient Medical Infornration source 101 is 

20 typically a form of database containing, for example, records of medical history, physical desaiptions. psychiatric 
records, laboratory tests results, cognition and intelligence test data, presaiptions and treatment of patients who par- 
ticipate in a healthcare provider's program. 

[0013] The Predictive Health Outcome Modeling process 102 off Figure 1 A is a process that produces a statistical 
model which can be used to predict whether a patient with a particular disease or condition and medical history is likely 

25 to suffer an adverse health outcome. The process of Inten/ention off At-risk Patients 103 includes: the Risk Stratification 
process 1 40 that is a database analysis process which derives a list of at-risk patients who have a high risk of suffering 
an adverse healtii outcome, and the Interventron Management process 160 that determines an intervention in the 
selected patient's healthcare treatment to decrease tiie possbility of such an adverse healtii outcome. 
[001 4] The operation of the disease management process of the present invention, as shown in Figure 1 A, is now 

30 described. Rrst, the Predictive Health Outcome Modeling process 1 02 receives a sample group of patient data from the 
Patient Medical Information database 100 for a given disease. In addition, the Predictive Hearth Outcome Modeling 
process 102 receives certain pre-determined statistical or other information for generating predictive models, shown as 
the Modeling Guidelines 104 in Figure 1 A. and generates a particular predictive model for a particufar disease to deter- 
mine the probatwlity of an adverse hearth outcome. The same or similar data coukl be used to determine the probability 

35 of developing a particular disease or condrtion which is associated witti an adverse hearth outcome. . 

[0015] The Risk Stratification process 140 receives the predictive model provided by ttie Predictive Hearth Outcome 
Modeling process 102 and analyzes the individual patient-specific data from ttie Patient Medical Information database 
100 with the predictive nrodel to identify a list of current patients that are at-risk of an adverse hearth outcome for a par- 
ticular disease. Once the list of patients is identified, the Intervention Management process 160 suggests an inten/en- 

40 tion in ttie treatment process of the patient tiirough contact wrth tiie patient, physician, or hearthcare provkJer. The 
process off Intervention off At-risk Patients 103 requires externally generated infformation about treatment regimens (e.g. 
Best Practice Guidelines) for given stages off disease progression, as well as particular interventions, which are shown 
as ttie Intervention and Medical Guidelines 1 05 of Figure 1 A. 

[001 6] Finally, ttie interventions rtself may be recorded, and once ttie process off Intervention of At-risk Patients 1 03 
45 has been completed, the resurts of these interventions, shown as intervention outcome measurements in Figure 1 A, are 
recorded in the Patient Medical Information database 1 00. This allows for a feed-back st^ where data after intervention 
can be fed back ttirough ttie whole process, erther to be again re-run ttirough the Risk Stratification sl^ to help analyze 
the outcomes or to become part of the basis for generating a new and revised Risk Stratification process. 
[001 7] To summarize, ttie disease management system analyzes ttie f tow of individual, patient-specific hearth infor- 
50 mation and inten/enes with the physician or patient whenever necessary to attempt to avoid adverse hearth outcomes 
and consequent high cost events. Disease management includes: 

1 ) Identifying ttie client organization and prospective program patient enrollees based at certain predetermined dis- 
ease states derived from research data. 
55 2) Utilizing medical claim, pharmacy claim, clinical data and laboratory data to assess disease states. 

3) Utilizing pre-defined interventions to manage the program. Examples of interventions ooukJ be mailing periodic 
notifications, mailing disease educational material, patient-inrtiated phone survey responses or even outtx)und call- 
ing performed by a staff off hearth care professionals. 
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4) Administering the process with case program managers who perform the necessary intervention with the dient 
(e.g. MCO, healthcare provider), doctor and patient. 

5) Recording interventions in patient care to determine if proactive disease management services improve specific 
disease outcomes. 

5 6) Processing inten/entipn management information back through an analytic process to determine the outcome of 
intervention. 

[0018] In the method of this invention, the case program manager (not shown in Figure 1 A, Ixrt whose functions are 
shown as part of the Case Management process 1 50 of Rgure 1 B, which is described in detail below) facilitates patient 

10 treatment by identifying to physicians patients who are likely to benefit from a change in therapy; and by suggesting 
therapies to the physicians: and by providing educational and treatment compliance assistance to patients {with the 
concurrence of the treating physicians). The case program manager does not diagnose disease or prescribe treatment 
regimens. Medical diagnosis and treatment is tiie sole responsibility of licensed physicians. 
[0019] By employing the process of the present invention, the case program manager identifies patients r«;eiving 

15 therapy and, more importantly, the subset of these who are not being treated in accordance with the preferred tr^tment 
regimen for the patient's disease state. This population of patients is very relevant to tills invention; from this population, 
the treatment regimen of those patients who are not receiving the prefen-ed therapy regimen can be autonratically iden- 
tified and influence to change habits or conform to the recommended treatment regimen. 

[0020] For convenience, in the subsequent desaiption of the present invention, the case program manager is shown 
20 as a single source of external information such as that from the Modeling Guidelines 104 tor the Predictive Health Out- 
come Modeling process 102, and for the Intervention and Medical Guidelines 105 for the process of Intervention of At- 
risk Patients 103. 

[0021] Generally, most functions of the case program manager are automated and implemented by, for example, a 
dedicated computer system. However, end users may: provide external information as a disease management program 
25 is initiated, provide changed or new parameters to a disease management program based on experience, or modify 
intervention techniques as needed. 

[0022] For most embodiments of tiiis invention, the roles of the case program manager are divided among multiple 
persons or entities. For example, one "case management" entity can identify patients at risk for becoming "high-cost" 
patients, another entity can contact physicians with this information and with treatment advice as well as with patient 

30 educational materials and treatment compliance devices, and yet a tiiird entity can contact physicians directiy. Still 
another entity can be re^>onsible for managing the tdentif ication off statistical Infornnation and creation of predictive 
models. As a result of carrying out tiie method of tiie invention, a larger number of patients receive appropriate thera- 
pies tiian would othenwise, and. consequentiy, a snraller number of patients suffer from serious disease progression 
ret^iring extraordinary, and expensive, care. 

35 [0023] The method of the invention typically involves at least several ti-eating physicians. One prefenred embodiment 
includes approximately 100 treating pti^icians, but is also effective with larger numbers of physicians, e.g., 250 to 500 
physicians, or more. 

The Disease Management System 

40 

[0024] A high level flowchart of tiie Disease Management System off the present invention is shown in Figure IB. 
Referring to Figure IB, the Disease Management system includes a Disease Management Data R^x>sitory system 
101 which includes the Patient Data Collection and Integration process 1 10 and the Disease Management Database 
120. This is where the event-level information resides. Next, the Disease Managanent system includes a Predictive 
45 Modeling process 130, a Risk StiBtif ication process 140. an Intervention Management process 160. and an Intervention 
Records and Tracking process 170. 

[0025] A Case Management process 1 50 receives Intervention information from the Intervention Management proc- 
ess 1 60 and Results from ttie Inten/ention Recording and Tracking process 1 70. The Case Manager 1 50 provides exter- 
nally derived information to the Predictive Modeling process 130 and Risk Stratification process 140. 

50 [0026] The Disease Management Data R^jository system 101 includes a Patient Data Collection and Integration 
process 110 and a Disease Management Database 120. The Patient Data Collectton and Integration process 110 
receives raw patient data from healtiicare sources, and processes the raw patient data to remove redundant information 
and format the raw patient data into a comrron, predeterminaJ format Initially, one or more sources of information are 
required which allow for identification of an initial population of patients. 

55 [0027] Typical sources of raw patient data may include, for example, hearthcare providers such as doctors, hospitals, 
pharmacies, other hearthcare providers, and payers who p^ for these services which all keep records for their patients. 
These records, however, may be scattered, difficult to access, have different formats, and contain duplicate or inconrect 
information. Therefore, a more accessible source for such information exists in the health care claims records of a given 
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benefits provider. These liealth care claims records are used in one exemplary embodiment of the invention. 
[0028] The Patient Data Collection and Integration process 110 stores the formatted patient information in the Dis- 
ease Management Database 120. which is the database storing the patient medical records, dinical data or other data 
used by the present invention. 

5 [0029] The Predictive Modeling process 1 30 of the present invention uses an identified disease, statistical restrictions, 
and a sample patient database to create a predictive model and rules which can identify patients, from a pr«jetermined 
identified disease patient population, who are at high risk to ^erse health outcomes. As us^ herein, the term "iden- 
tified disease" refers to a particular disease about which the client may t»e concerned, such as asthma, depression or 
congestive heart failure (CHF). 

10 [0030] The Risk Stratification process 1 40 of Rgure 1 B applies a statistical predictive model and rules to patient data 
from the Disease Management database 1 20 corresponding to a group of patients selected from the Disease Manage- 
ment database 120 based on a predetermined criteria. TTie predetermined criteria could be "all client (MCO) patients" 
or "all new employees" for example. The Risk Stratification process 1 40 identifies a subgroup of at-risk patients and cre- 
ates an interv^ion list from the subgroup. 

IS [0031] The Intervention Management process 160 schedules and performs interventions for each identified patient 
on the intervention list, such as sending letters or educational materials, and making phone calls or home visits, to these 
at-risk patients. Rnally, ttie Intervention Records and Tracking process 170 keeps a record off the interventions per- 
formed and tiieir effects. 

[0032] "me operation of the Disease Management System as illustrated in Rgure 1 B is now described. 

20 [0033] Rrst, a particular disease of concern, as well as ottier predetermined restrictions, are identified by tfie Case 
Management process 150. The identified disease and restrictions are supplied to the Predictive Modeling process 130. 
The Predictive Modeling process 1 30 receives a subgroup of patient medical data from the Disease Management Data- 
base 120 corresponding to patients having tiie identified disease and meeting other predetermined statistical criteria 
determined from research data. TTie Predictive Modeling process 130 tiien creates a predictive nwdel and rules from 

25 the subgroup of patient medical data which can identify patients from a predetermined identified disease patient popu- 
lation who are at-risk to adverse health outcomes. 

[0034] The Risk Stratification process 1 40 receives the output predictive model and rules from the Predictive Modeling 
process 130. and further rules from the Case Management process 150. Based on the information provided by the 
Case Management process 150. medical and clinical information for a group of patients contained in the Disease Man- 
30 agement database 120 is retrieved, and the group of patients is the predetermined client*s identified disease patient 
population. The Risk Stratification process 1 40 then uses the predictive model and rules to identify a high-risk subgroup 
of patients from tiie predetermined client's identified disease patient population who are at-risk of adverse health out- 
comes. 

[0035] Identifying a high-risk subgroup is a subjective undertaking which is defined by the operator. It is not a procru- 
35 stean bed. For example, "high-risk" can be determined based on the severity of the disease or condition. Or it can be 
driven Ijy available resources; there may be only so many resources available versus the cost off providing useful inter- 
ventions. A classic example of "high-risk" is the triage approach used in dealing witti nrrajor catastrophes: doni treat 
those who will die anyway, don't treat those who will live anyway; treat ttiose for wfK>m available intervention may result 
in survival or a lessening of permanent disability. Anottier example is to define the high-risk subgroup as comprising a 
40 certain percentage of the total group based on how many patients a particular operation can handle. So if the through- 
put off a particular system can only handle or manage interventions In 1000 patients on a given day, then the 1000 
patients nrost in need out of the total population will t>e defined as ttie "high-risk" subgroup. In a similar way, the inter- 
vener may have only enough money to usefully intervene in 1 000 patients in six months. Hence by definition ttie 1 000 
patients nrost at risk become the "high-risk" subgroup. Another example is one where clinical outcomes are ranked from 
45 1 to 5 in ternrs off possible useful outcome, and it is decided ttiat those with a possibility off a good outcome ranking of 
3 or greater shouW be progressed as tiie "high-risk" subgroup. In addition, age and age-related likdihood of an adverse 
outcome, or a positive outcome, may be used in defining a "high-risk" sutjgroup. For example it may be decidaJ to 
define high-risk as ttiose who are female, past menopause, and have a family history of an estrogen<lependent dis- 
ease. And 2 or more of ttiese factors will usually be combined in creating the algorittim for identifying the "high-risk" sub- 
so group. These are but a few examples of how one might detfine "high-risk". 

[0036] It should be noted also that afthough ttiis step is described in terms of identifying a single "high-risk" subgroup, 
graded levels of intervention can also be delined and factored back into this analysis. So rather tiian d^ining a high-risk 
subgroup, one could define a set of subgroups where each was accorded a particular risk factor, and then intervention 
carried out on a selected set off subgroups t>ased on different levels of accessed risk. 
55 [0037] Once the high-risk subgroup, or a set of target subgroups, has been identifi^. ttie Risk Stratification process 
140 creates an intervention list ranking the patients according to a predetermined criteria. The intervention list is us^ 
by ttie Intervention Management process 160 of the present invention to schedule and perform interventions, such as 
sending letters or «iucational materials, and making phone calls or home visits, to tiiese high risk patients to prevent 
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and/or improve their likely health outcomes. 

[0038] The Intervention Management process 160 takes a data feed from the Disease Management Database 120. 
and the data is "client" identified disease patient data which is normalized into the Disease Management Data Reposi- 
tory format. This data feed or detection process has parameters and rules receival from the Case Management proc- 
5 ess 150 that identify a specific patient meeting the conditions for participating in a disease program. This detection 
process provides a population for consideration in the qsecif ic tdentif red disease program. 

[0039] The Intervention Management process 160 also passes intervention contact data back to the main Disease 
Management Database 120 and the intervention list to the Case Management process 150. TTiis Intervention contact 
data is used in the analytic process to. for example, determine the success of the particular form of intervention. 
10 [0040] TTie Intervention Record and Tracking system 1 70 ke^ a record of the interventions and their effects, from 
which the Case Management process 150 can update external information used by the Predictive Modelir^ process 
130. as well as guidelines for inten^entions, and the Best Practice Guidelines to improve treatment regimens for an iden- 
tified disease. 

[0041] The following sections describe in detail each of the processes of the Disease Management system of the 
15 present invention, as illustrated by Rgure 1 B. 

The Disease Management Data Repository and Data Integration 

[0042] The Disease Management Data Repository 101 is described with reference to Rgure 2A, which Is a high level 
20 flowchart illustrating the raw patient data acquisition, pre-processing, and database formation of the present invention. 
The Disease Management Data Repository 101 includes the Patient Data Collection and Int^ration process 1 10. Dis- 
ease Management Database 120. and a Research Database 250. 

[0043] The Patient Data Collection and Integration process 110 includes Reimbursement Claims sources 200 as a 
data source, a raw Patient Data Pre-processing process 210 to "clean-up" ttie raw patient data, a Conversion process 
25 220 for converting the raw data to a predetermined format, and an Update Patient Data process 230 to update patient 
information due to subsequent events or interventions (also called event-level information). 

[0044] In ttie Patient Data Collection and Integration process 1 10. Reimbursement Claims sources 200 provide raw 
patient data to ttie raw patient data pre-processing algorithm. The exemplary sources of infornrration, which altow for tiie 
Identification of a population of patients who are currently provided medical treatment, are the clinical records and the 
30 health care claims records of many healtiicare benefit providers. As is known, claims for drug reimbursement, doctor 
visits, hospital stays, and laboratory tests are received and processed for payment/reimbursement. In the exemplary 
embodiment of tiie present invention, tiiis daims information is enteral into, for example, a DB2 or Sybase database 
on a computer system (not shown). 

[0045] The present invention is not limited, however, to these Reimbursement Claims sources 200 as shown. In 
35 anottier embodiment of the invention, data concerning individuals, such as demographic data; social data; personal 
data such as lifestyle, a history of sexual abuse or parental neglect or physical abuse, nutritional status; geographic 
data; family history; or other data can be used to populate the Disease Management Database. 
[0046] The method of the invention is typically canried out with the assistance of an eledronic database for storage, 
and retrieval, of data concerning an individual, such as medical data, demographic data, pharmaceutical data, diagno- 
40 Sis data and treatment data, from reimbursement claims sources 200. For example, the following pharmaceutical data 
can be retrieved from reimbursement claims: 

a) patient identifier 

b) drug prescribed 
45 c) drug dosage 

d) annount of drug 

e) duration of drug therapy 

f) dates of recent prescription f ills/refflls 

g) provider identifi^. 

50 

[0047] The data are stored preferably in machine-readable form and are recoverable In discreet, searchable f ieWs witti 
a discreet record for each patient. Each record also preferably comprises a f ie(d for noting whether or not one or more 
case management interventions as described herein have been undertaken. The data are stored in a computer and 
accessed through customized datat)ase utilization software. Such software provides searching and reporting (display, 
55 printing, and electronic distribution) capability. 

[0048] Figure 2B is a high-level block diagram illustrating ttiree exemplary sources of information suitable for use witti 
the present invention. As is illustrated in Figure 2B, ttie claims inlbrmation of such a provkJer would typically Include 
three sources: pharmacy (Rx) daims 202. doctor (DR) daims 204 and ho^ital (HL) claims 206. As listed on the blocks 
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representing the claims infornnation, many types of information vyould be available from the re^ective claims including 
drug codes, physician's names, diagnosis codes, procedures, various dates and other relevant information. Much of this 
information is referenced using codes, such as drug codes, procedure codes and illness codes. 
[0049] Continuing with Figure 2A, the Raw Patient Data Pre-processor 210 performs data integrity checks which iden- 
tify and process rejected or reconciled claims. 

[0050] To make the use of the database more efficient, the database utilization subalgorithm (not shown) of the Raw 
Patient Data Pre-processing algorithm 210 has the capability of eliminating redundant entries, of eliminating entries for 
patients who have become ineligible and of ignoring records for which a case management Intervention has been 
undertaken within a preset period of time. 

[0051] Second, the Conversion algorithm 220 reads the source data files and populates the Disease Management 
Database 240 with the patient information in a predetermined database format. The Disease Management Database 
240 of the present Invention uses Sybase, but any similar database product may be used. 

[0052] Finally, the Update Patient Data process 230 of Figure 2A receives intervention management information from 
the Intervention Management process 160 and Intervention Recording and Tracking process 170 and updates the 
patient Information of the Disease Management Database 120 to Include information about interventions regarding the 
memt>er patient. 

[0053] A more detailed flowchart of an exemplary embodiment of the Conversfon process 220 is shown in Rgure 3. 
[0054] Referring to Figure 3. the File Manager 31 0 receives patient data files and kJentif ies the incoming files, verifies 
that they are suitable for processing, and stores information about each file in a file inventory database. If the file is Hier- 
archical, the File Manager 310 sends the file to the Hierarchical File pre-processor to read the contents Into flat files. 
The flat files are then stored into the Disease Management Database 240 by the Flat file Processor 330 using the infor- 
mation contained In the Input configuration table 340 and Output configuration table 350. The patient data is then stored 
in the database using a Data Model. 

[0055] Figure 4 is an illustration of an exemplary Data Model as used in the patient data repository of an embodiment 
of the present invention. The Data Model Includes a Source Data Inventory 410, which records aspects of incoming 
data during database population; an Exception Handling process 420 which handles data exceptfons during the popu- 
lation process; Client Tables 430. which contain lists of the Disease Management provider clients: and a Member Table 
440, which includes member specific klentity Information. 

[0056] The Data Model also includes, for each member patient in Member Table 440, a Claim Table 450, which Is a 
record of healthcare activity for a single menrtber; a Laboratory Table 460, which represents the entities and relation- 
ships Involved in gathering clinical test data for a given member; and a Diagnosis and Procedure TaWe 470. which con- 
tains a ra>ord of related cfiagnoses and medical procedures for a given claim. 

[0057] The organization process of the Data Model is as follows. Referring to Figure 4, the source Data Inventory 410 
records the progress and nature of incoming data during the database population process. The Exception Handling 420 
handles data exceptions during the population process. The exception may be caused by missing values, values out of 
range, or other errors in the data, and the Exception Handling 420 resolves these exceptfons when tiiey occur by throw- 
ing away the data, retaining some of the data, or resolving the errors based on available information. The Source Data 
Inventory 410 provides received client data to populate the database with Client Tables 430. 
[00^] The Qient Tables 430 contain lists of the Disease Management provider clients which have patients and are 
subscribing to the system and method described In the invention. Each client in the Client TaWe 430 has patients 
defined as members in the Member Table 440. The Member Table 440 includes such information as member name, 
date of birth, and gender. 

[0059] For each member patient in Member Table 440. a Qaim Table 450 is kept. Each daim in Claim Table 450 is a 
record of healthcare activity for a single member. Data items recorded are, for example, dates when the daim was ini- 
tiated or resolve, drug and prescription information, details of a medfoal examination, the member's primary or other 
physidans, and encounter services or procedures provided. 

[COSO] In addition, the Laboratory Table 460 represents the entities and relationships involved in the requisition, 
accession, and resolution of lakwratory tests performed for a given member. Data items recorded are, for example, 
blood tests, glucose tests, or otiier tests based on a single analyte. 

[00S1 1 Finally, the Diagnosis and Procedure Table 470 records primary and one or more secondary diagnoses for a 
given claim, which are expressed as ICD-9-CM codes. Diagnoses can be grouped togetfier into a Diagnosis- Related 
Group (DRG). and a DRG is one of 495 classifications of diagnoses in which patients denrronslrate similar resource con- 
sumption and length of stay patterns. The Diagnosis and Procedure Table 470 also records procedures corresponding 
to each diagnosis, and these procedures can be expressed as out-pati«it CPT codes, in-hospital HCPCS. or otfier pro- 
prietary codes. 

[00S2] A second, identified disease specific datat>ase is created for the purposes of providing a datat>ase of identified 
disease patient data for tiie Prajictive Modeling process 130. Returning to Figure 2A. this database is the Research 
Database 250 which is a daims level database In a predetermined format, such as SAS format. Although Rgure 2A 
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shews that the identified disease sample patient data used to populate the Research Database 250 is provided by the 
Disease Management Database 120. the present invention is not so restricted and the Research Database 250 can be 
populated from Reimbursement Claims sources 200 using an appropriate pre-processing algorithm. 
[0063] Exemplary formats illustrating the research database format for each of the Rx, DR, and HL daims of the 
5 records contained in the research datat>ase are shown in Figure 5. As shown in Figure 5. claims are listed from claims 
1 to daim x and the appropriate information, for the particular service provider being claimed, is also presented. The 
DB2 database still represents a source of raw data elements which require processing by the raw patient data pre- 
processing algorithm 210. Subsequently, the data is routinely downloaded into a Research Database 250. 

10 Creation of Predictive IVfodels 

[0064] Turning to the statistical prediction modeling. Figure 6 is a high level flowchart illustrating the sanple patient 
data extraction process and predictive nrnxjeling process for an identified disease according to the present invention. As 
shown in Figure 6, the Predictive Modeling process 130 includes the steps of 1) Extracting Identified Disease Sanple 
15 Data 610; 2) Performing a Quality control operation (optional) 620; 3) Checking Whether the Data is Statistically Valid 
630; 4) Converting Claims level data into Event Level Data 640; 5) Processing the Event Level Files into Analysis Files 
650; and 6) Processing the Analysis File using Statistical Techniques to create an identified disease prediction model 
and rules. 

[0065] Referring to Figure 6, the process of determining a predictive nrxxlel begins with step 610, Extracting Identified 

20 Disease Sample Data. The extraction process of step 610 receives the sanple patient data from the Research Data- 
base 250 and an identified disease from the Case Management process 1 50 when the data has been converted to SAS 
format. SAS procedures process the information to: 1 ) extract patients with the identified disease (step 61 0), 2) process 
the claims level information into event level information (step 640). 3) using predetermined variables and timeframe 
schemes, generate analysis files for analysis purposes (step 650) and 4) create a prediction mo6e\ as a function of 

25 those variables most reflective of the conelation to an adverse health outcome (step 660). 

[0066] It should fc>e mentioned that, from a statistical perspective, an important consideration in developing prediction 
nrKxiels from datasets is sample size. To maximize the integrity of the prediction model, a valid sample size is an inpor- 
tant factor, and sample sizes required to determine prediction equations depend on the magnitude of assodation 
between variat)les. As these associations are unknown, all patients within any individual plan are initially included. 

30 [0067] Ihe first step, extracting patients with an identified disease or condition (step 610). uses various parameters 
provWed either by the case program manager, research source, or other healthcare professional to define which 
patients qualify for the overall initial universe of patients with the klentrf led disease to be considered. 
[0068] For example, in one exemplary embodiment of the present invention, only patients having a continuous enroll- 
ment with the benefits provider of 1 2 nwnths or longer and having a daim for depression or treatment vnth anti-depres- 

35 sant medication are eligible. Of course, these criteria are exenrplary and could be modified such that 24 nxMTths or 6 
months of enrollment is satisfactory or that an indivkiual must be 18 years of age. In the exemplary embodiment of the 
present invention, the Extracting of Identified Disease Sample Data, step 610. extracts all claims data for patients wHh 
either an appropriate code for an klentified disease (such as depression; see Appendix I) or for treatment with a drug 
used in treatment of the klentified disease (for example, for depression, an antklepressant drug; see Appendix III). 

40 [0069] It should be noted that in the health care industry various codes are used in daims information for indicating 
wfhich procedures, treatments, diagnoses, drugs, etc. are being daimed. For the exemplary enrtxxliments of the 
present invention, examples of the selected codes are shewn in Appendfces 1 and II. TTiese codes were found in Phy- 
sidan's Cunent Procedural Terminology (CPT), American Medical Association (1995) and St. Anthony's 1CD-9-CM 
Code Book (1994) which are both hereby incorporated by reference for their teaching of codes and sources of codes. 

45 As will be appreciated by those skilled in the art. any set of codes, representative of the various procedures, treatments, 
diagnosis, drugs, etc. relevant for use with the present invention wouW suffice. References to such codes occur 
throughout this specification. 

[0070] Subsequent to the extraction process of step 610 of Rgure 6. the daim adjustment and integrity checks are 
optionally performed in the data Quality Control step 620. The Quality Control step 620 is optional, as. for exanple. the 

50 patient data for an identified disease may not require the step or the original Disease Management Database 120 may 
already be of sufficient quality due to the raw Patient Data Pre-processing step 210 (shown in Rgure 2). 
[0071 ] One method of Quality Control of step 620 generates, from the dataset defined above, intermediate output files 
which contain sets of frequency counts for processing purposes. In one exemplary emlxxfiment of the present inven- 
tion, with depression as the identified disease, intermediate output files for the following charaderistics are generated 

55 for review: 

a. frequency counts of unkjue members by sex, age groups (0-9. 10-19...) and enrollment duration by months 
induding: 
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i) Tables showing count of members by sex. ii) Table showing count of members within age groups, iii) Table of 
counts of age groups broken down by sex, iv) Table of enrollment duration by months i.e. . 1 month to maximum 
number of months possible. 

b. frequency counts of ICD codes for depression (Appendix I), i.e., number of members having at lieast one hit with 
each of the ICD codes in Appendix l-a any level ii) as first code. 

c. frequency counts of anti-depressant drugs (Appendix II): 

i) number of members who have at least one daim lor each of the drugs in Appendix III. 

d. count of members who became eligible for processing due to ICD code only, by drug only, and by both ICD code 
and drug. 

e. frequency counts of numbers of all claims within each file (HL, DR, Rx) by mender. 

f. frequency counts of ICD codes (use only the first 3 digits of ICD codes) of any nature in DR (any position) and HL 
files - at least the top 10 with frequency of each. i.e.. 2 tables one each for DR and HL files. 

g. frequency counts of hospitalizations by calendar month. Counting calendar month backward from last month of 
eligibility or data availability. The last nwnth for which data is available will be month 1 . the penultimate month with 
be month 2 etc. 

h. frequency counts of procedures related to depression (CPT codes. Appendix l-b). 

I. frequency counts of all CPT codes (to the level of the first 3 code digits) - at least the top 10. 

[0072] The above frequency counts for use in performing preliminary evaluations as to the integrity of the data are 
exemplary and could be nrxxiif ied to indude/exclude parameters which are shown to be more/less useful. 
[0073] In another exenrplary embodiment of the invention, with Congestive Heart Failure as the identified disease, the 
following frequency counts are generated: 

A) Rrst, a frequency count of the nunrtoer of enrollment periods for the members is generated. Then, for members 
with multiple enrollment periods of at least 6 months duration, it is determined if a CHF diagnosis is present in each 
enrollment period. Consequently, enrollment periods without a CHF diagnosis are excluded and. for members with 
multiple enrollment periods that have a CHF diagnosis, only the most recent enrollment period that contains a CHF 
diagnosis is kept. 

B) For the one enrollment period for all remaining members, all costs, denoted ALL COSTS, encountered by that 
member during the entire enrollment are identified. A complete proc univariate for ALL COSTS is provided for each 
plan separately and all plans together. It should be noted that "proc univariate" is a SAS procedure which generates 
descriptive statistics (e.g.. mean, standard deviation, etc.) 

C) From the ALL COSTS determined above, costs which are specifically cardiovascular (CV). denoted CV COSTS, 
are identified. In doing so, a cost is considered to be a CV COST if a daim from the DR or HL file has any CV ICD- 
9 code in the first or second position. If a claim from the Rx file is from therapeutic class 04000 then it is counted 
as a CV daim and count cost as a CV cost. A conrplete proc univariate for CV COSTS is also provided for each 
plan separately and all plans together. 

D) From the CV COSTS, those costs which are specif icaily congestive heart failure related, denoted CHF COSTS 
are identified. A cost is considered to be CHF COST if a daim from the DR or HL file has any CHF ICD-9 code in 
the first or second position. A complete proc univariate for CHF COST is also provided for each plan separately and 
all plans together. 

E) For all member enrollment periods remaining, the total member months for each plan is calculated separately 
and together. In doing so, a member is considered enrolled during any month thiat they were enrolled for at least 
one day For this, a complete proc univariate is provided for member nx)nths for each plan separately and all plans 
together. 

F) Finally, a unique member count is provided for all patient status code = 20 within the remaining enrollment peri- 
ods. It is noted that status code = 20 indicates that the patient has expired or did not recover. 

[0074] It should be noted that, regarding the cost calculations, the following guidelines apply in the exemplary errtKxi- 
iment of the present invention: 

a. the cost of inpatient hospitalizations, emergency services, physician/outpatient, and other medical services on a 
per daim basis are considered to be: 

AMTPAID + Af^TCOPAY + AMTRESERVE + AMTDEDUCT 

b. the cost of drugs are considered to be: . 
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AMTPAID + AMTCOPAY 

where AMTPAID is the amount paid, AMTCOPAY is the amount co-payed. AMTRESERVE is the amount reserved 
and the AMTDEDUCT Is the deductable amount. 

[0075] ft should also be noted that, for purposes of a cost hierarchy, the following rules were used In the exemplary 
embodiment of the present invention. 

1 . Only hospitalizations for CHF can spawn other events. 

2. Hospital costs include all Rx. procedure, physician charges. 

3. Hospital visits can generate Rx and procedure events with costs set to zero (included in hospital cost). 

4. Hospital visits cannot generate separate doctor visit events. 

[0076] Once again, the above information, which is used to perform preliminary evaluations as to the integrity of the 
data, is exemplary and could be nrxxJif led to indude/exclude parameters which are shown to be more/less useful within 
the spirit of the present invention. 

[0077] With this information, a "quality check" is performed on the initial universe of identified disease patients to make 
sure that the final results, i.e., prediction model. Is not unreasonably skewed due to invalid input information. TTiis 
processing for maintaining data quality. Quality Ckintrol step 620, produces intermediate output files, and albws for a 
refinement of the extracted information by, for example, checking to see if an imbalance exists in the extracted informa- 
tion such as all claims are from individuals over 60 years of age, all claims are from men, or other data imbalances 
which would olhenwise taint the integrity of a prediction model. Step 620. in the exemplary embodiments, is performed 
manually by viewing the intermediate output files. It Is contemplated, however, that using various threshokl values, the 
frequency counts can be automatically scanned for a potential imbalance. 

[0078] Having now extracted and refined the claims level information according to various predetermined criteria 
deemed relevant for sut)sequent processing purposes, the information is converted into an event level format. 
[0079] Returning to Figure 6, the next step is the Convert Claims Level Data to Event Level step 640. To provide 
processing flexibility, particularly in assigning time windows for analysis, the above-mentioned second step 0-e.. con- 
verting the claims level information into event level information, step 640) is employed to generate two primary data files 
from which an analysis file can be created. 

[0080] In the exemplary embodiment of the present invention, primary data file 1 is a member level file and contains 
all data of a static nature (i e.. not time sensitive) such as 1) Member Key, 2) Date of birth. 3) Gender, 4) First available 
date of enrollment (i.e., start of dataset (1/1/92) or enrollment date), 5) End date of enrollment (I.e., end of dataset or 
last date of enrollment). 6) Date of first identified disease event (for example, first prescription for antidepressant, or 
hospitalization for congestive heart failure), 7) Date of last hospitalization, 8) Number of records in events file (primary 
file 2), and 9) Mode of entry into the dataset (e.g.. i) Anti-depressant drug only, ii) Depression diagnosis only, iii) Both 
anti-depressant drug and depression diagnosis). 

[0081 ] Primary data file 2 is an event level file with a record for each event ordered by member and the chronological 
date of the event, and. in the present invention, presented in descending order of event date. 
[0082] It should be noted that an event, sometimes referred to as an episode, is an occurrence which, based on clin- 
ical knowledge. Is deemed relevant to the identified disease. Having knowledge of what raw data elements are available 
from the claims, a set of events is defined directly or indirectly from the data elements where events can be based on 
an individual data element, a combinatton of data elements or it can be derived from indivkJual or multiple data ele- 
ments. 

[0083] Rgure 7A is an exemplary list of events and fbrnnat for primary file 2 (an event level file) for depression as the 
identified disease. As shown in Figure 7A, the entries provided include: 

1 . Hospitalization for depression 

a. Any hospital claim klentif led by hospital site code. 

b. Having a from and through duration of at least 1 day. 

c. Having ICD 9 code. 

d. Depression ICD 9 code occurring at any position. 

e. Illness indicator (Appendix V) 1 = major illness. 2 = suicide. 3 = major illness and suicide. 0 = everything else. 

2. Emergency room for depression 

a. Emergency room visit identified by emergency room site code. 

b. Having ICD 9 code (see /Appendix l-a). 
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3. Doctor (non-hospitaQ visit for depression 

a. Any doctor claim. 

b. Having ICD 9 code (see Appendix l-a). 

c. Category: Psychiatrist =- 1 . all others = 0. 

4. Prescription for SSRI 

a. SSRI (selective serotonin re-uptake inhibitors) therapeutic dass 5.51.3. 

b. Cost = 0 if generated from a hospital admission. 

c. Category indicator = blank 

5. Prescrption for (Tricyclic antidepressants) TCA or (Monoamine Oxidase inhibitors ) MAOl 

a. Therapeutic classes 5.5.1.1 (tertiary amines), 5.5.1.2 (secondary amines). 5.5.1.4 (Monoamine Oxidase 
inhibitors). AND 5.5.2 

b. Cost = 0 if generated by a hospital admission 

c. Category indicator therapeutic class 1 = 5.5.1 .1 . 2 = 5.5.1 .2. 3 = 5.5.1 .4, 4 = 5.5.2 

6. Prescription for other neuroactive drug (From Rx file) 

7. Procedure for depression (from DR or HL files) 

Category: CPT codes or ICD procedure 

0 = Psychotherapy All CPT and ICD codes in Appendix l-b not listed below. 

1 = Diagnostic 90801. 90820, 90825, 90830, 

90862 

94.0x,94.1x, 94.21, 99.22. 
94.23 

2 = Shock therapy 890870. 90871 2 

94.24, 94.26, 94.27 



For this entry, costs are assigned to tiie doctor visit or hospitalization in which the procedure occurred. 

8. Hospitalization not for depression 

It shouW be noted that items under entry 8 could have been performed for a condition other than depression 
although these patients got into the cohort by virtue of receiving a depression diagnosis or receiving and antide- 
pressant at some time making it likely these procedures were for depression. 

a. All hospitalization having from and through dates of at least one day duration. 

b. Major illness ICD 9 codes (see Appendix V). 

c. Category as in 1 above (1 = major. 2 = suicide. 3 ^ both. 0 = all others) 

Counts for entries 9-13 are aggregated for each month. The date is that tor the first occunrence of the identified 
events. In the numl)er field, tiie number of identified events occun^ing in that month are summed. 

9. Emergency room not for depression 

a. Emergency room visit Identified by Emergency room 

10. Doctor (outpatient) visit not for depression 

a. Any doctor visit. 

b. Excluding visit with a depression diagnosis (Appendix l-a) i.e., not in 3/above. 

1 1 . Prescription for possibly related drugs 

Drugs identified in Appendix IV 

12. Presaiption for all other (non^epression) drugs 

All drugs not included in Appendices III or IV. 

13. Procedure not for depression (from Dr and HL files) 
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a. Category indicator 1 = major procedures, 2 = minor procedure (see Appendix IV). 

[0(S4] Figure 7B illustrates the exemplary list of events and format for primary file 2 (an event level file) for the exem- 
plary embodiment with congestive heart failure as the identified disease. This embodiment exemplifies that the primary 
5 files 1 and 2 can be subdivided using the following exemplary ground rules which provide counts for the various events: 

I. Count as a hospitalization event, denoted HOSPITALIZATION, (using both 1st and 2nd ICD-9 codes) a daim hav- 
ing a from and through date of at least one day and having a site code of 04. It is noted that a site code distin- 
guishes between the sites at which the service under consideration took place (e.g.. emergency room, doctor's 

10 office, etc.). ft should be noted that costs go to 1st ICD-9 code category only Also, if a new hospitalization occurs 
within one day of discharge from a previous ho^taiization, the two hospftalizations are bridged into one. If a new 
hospitalization occurs greater than one day following a previous ho^italization. the second hospitalization is con- 
sidered a new one. 

II. Count as an emergency room visrt event, denoted ER VISIT, (using both 1st and 2nd ICD-9 codes) a claim hav- 
15 ing a site code of 07, 08 or 10 OR a claim with the following the Hospital Common Procedure Coding System 

(HCPCS) codes: A0010-A0070, A0215-A0225, A0999 wrth a provider code = 81. It should be noted that costs go 
to 1st ICD-9 code category only 

III. Count as an office visit event, denoted OFFICE VISIT, (using only one ICD-9 cede) a daim having a sfte code 
of 01 or 06 and having a unique date of service (DOS) but allow for different provider keys on the same DOS (if 

20 same provider key on same DOS, consider to be the same office visit) BUT if an office visit event occurs during a 
hospitalization, do not generate an office visit event (Attribute all costs for this event to the hospitalization). ALSO 
count as an OFFICE VISIT a daim with the following HCPCS codes: A0080-A0210 with provider code = 81 . For all 
other office visit events, costs go to 1 st ICD-9 code category only. It should be noted that the following provider keys 
are not considered as separate office visits and should be txidged with an office visit that occurs on the same DOS 

25 if one exists: 1) 24 (therapeutic radiology), 2) 34, 35 (independent lab), 3) 55 (hosp o/jjat lab x-ray). 

[0i335] The three event types illustrated above are then furthe- defined according to the assodated Diagnoses. 
[0086] The next step of Figure 6 is the Processing of Event Level Files into Analysis Files, step 650. After generating 
the two primary files using the above described instructions con-esponding to step 640, further processing using time- 
30 frame information and selected variables (ind^endent and dependent variables) is perform^ on the event level data 
to generate an analysis file, at step 650. 

10W71 Figure 8 shows an exemplary format for the analysis file. As shown, the fonmat of the analysis file includes a 
list of members in a first column of a tat»le. Across the top of the table is a list of variables, described in detail t>elow. 
The body of the table provides indications as to a member's relation to a listed variable. 
35 [0038] In particular, the processing from the primary files to the analysis files in step 660 indudes an algorithm 
defined, in part, by a time window and a pluralrty of variables. The algorithm can be re-programmed for vartous time win- 
dow adjustments as well as variable niodifications. The analysis file generated at this step Is a member level file (i e., 
or^nized with respect to members). The main analysis files are member level files derived from the information in the 
primary files. 

40 [0(^9] Each main analysis file is aeated to take into account a single reference time window of censored events and 
prediction window of Interest for that file. Each new time window applied to the data. In the exOTplary embodiment, 
requires another main analysis file. 

[OtBO] To generate the analysis file, a time window scheme, along with a plurality of variables. Is applied to the event 
level data. 

45 ] Discussing the variables first, induded in the processing are both ind^ndent and dependent variables. The 

independent variables basically represent potential predictors of the adverse heafth outcomes; whereas, the dependent 
variables basically represent the adverse heafth outcome to be predicted. 

[0CQ2] To determine exenrplary independent variables for step 650. as many of the original data elements as possible 
are used, assuming nothing about the identified disease. Then, based on clinical knowledge about the identified dis- 
50 ease, addftional variables are created. FurthernrK>re, combinations of the data elements and/or variat>les, based on clin- 
ical krK3wl6dge, are used as variables. Finally, some variables may be created and used based on their potential utilfty 
as a leverage point in disease management. 

[0093] In the exemplary embodiment of the present invention, tiie pluralfty of variat>les, in addftion to each of the items 
in tiie event file, currentiy used by step 650 in the SAS routine for generating an analysis file for the exemplary embod- 
55 iment witti Congestive Heart Failure (CHF) as the identified disease are shown below in Table 1 . ft is noted tiiat each of 
the events in Figure 7B is automatically considered an independent variable for processing. 
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Table 1 



Addrtional Independent Variables of Interest: 




1. 


Aae (at time of 1st CHF diaonosis or drua theranv - onti of thp trinlp^ 




2. 


Gender (M/R 

IVld tlVtfl J 




3. 


HMO Membershio (identification of oarticular HMO) 




4. 


Site of first CHF diaonosis (fiitn cndA\ 




5. 


Ischemic Heart disease (Y/N) 




6. 


Diabetes (Y/N) 




7. 


Adverse Lifestyle Diagnoses (Y/N) 




8. 


Cardiac Dvsitivthmias (Y/N) 




9. 


Ottier Heart Disease (Y/N) 

■ vl 1 1 vvll L L^lwwC19 V I t f 1 ^ 1 




10. 


Hvoertensive Disease (Y/N) 




11. 


Numhfir of Co-MnrhlH rliQaaQA*^ fO-y) 




12. 


NunrihPf rrf ACF inhihitor nrocrrrntinnc /n.v) 




13. 


Number of digoxin prescriptions (0-x) 




14. 


Number of loop diuretic prescriptions (0-x) 




15. 


iiiijiiiucr Ul uiiici picouipnurio (U-Xy 




16. 


I^UIIUCI Ul 1 lUI i V ^/l OoU i^Uwi lO lU AJ 




17. 


mcuiuciuuii ruoocooiuii nauQ ^i.A/rnpiianc6 measurey 




18. 


Number of CHF tiospitalizations 




19. 


Number of CHF emergency services 




20. 


Nil ffnh^r nf nh\/df?ifan nffir'o uicitc 
iYUiiH.id Ul |Jiijfoiv^aii uiiiwo vioilo 


21. 


Total Costs 






III 1 ciuciii nuo^iicii VA/olo 






Emergency Room Costs 






Doctor Costs 






1 1 lai 1 1 t€x\*j v/uoio 


22. 


f^nnHiAtfacpi ilar fVvcte 
V/cti uiuvdouuicti wuou> 






In-Patient Hospital Costs 






Emergency Room Costs 






Doctor Costs 






Pharmacy Costs 


23. 


CHF Costs 






In-Patient Hospital Costs 






Emergency Room Costs 






Doctor Costs 



[0094] Turning to the dependent variables, potential dependent variables, for example, contemplated for use witti ttie 
present invention are results to be predicted. For CHF, such predicted results include: 
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1 . Ho^talization [HL) for CHF. TTiis is a dichotomous variable which is referred to as the HL indicator such that HL 
= 1 if an admission occurred, othenrvise the indicator equals 0. 

2. High Cost. For example, the High Cost indicator may be defined as the highest 10% of resource utilization meas- 
ured in dollars. Resources count^J from time of cost in the top 10% of the first CHF diagnosis or receipt of first 
CHF-related drug (In the record) + 1, 3 and 6 months - separate analyses for each time period. Again, this is a 
dichotomous variable referred to as the High Cost indicator such that if the patient, for example. Is in the top 10%, 
High Cost = 1, otherwise High Cost = 0. 

The High Cost indicator, in the exemplary embodiment, could also be defined as the distribution of total cost 
per member (PMPM) in the prediction region (B to C). TTie High Cost indicator Is set to 1 for the 10% of membere 
with the highest PMPM in the Total Cost distribution and set to 0 for all others. 

3. Death. 

[OQBS] Although only three dependent variat)!es for the given example are listed atwve. as those of ordinary skill in 
the art will appreciate, other known or yet unknown variables consistent with the goals of the present Invention may also 
suitak>ly serve as a dependent variable within the scope of the present invention. 

[0G36] Turning to the time window aspect of the generation of the analysis file. It should be noted that there is one 
analysis record for each selected member. 

[0097] In the present invention, a scheme, as descried below, has been developed for d^ining prediction zones and 
censoring data to create the analysis file. That is, referring to Figure 9, a time window t>asically defines a prediction zone 
or region 910 and an events window (analysis region) 912 from where activity is used to predict something in the pre- 
diction zone. As those skilled in the art will appreciate, ^itional time window schemes may also adequately serve the 
present invention. 

[0^208] For purposes of explanation, the time that the claims history covers is referred to as the time window that starts 
at sotne point *A' and ends at point 'C*. The time interval Is divided into analysis and prediction regions by point 'B' such 
that A<B^C. That is to say. B' represents the present. 'A* represents the farthest past event and 'C* represents the far- 
thest future event. 

[0(^9] By way of example. Jane Doe's analysis record is based on claims from 1/1/91 through 6^0/93. Therefore, 
A=1/1/91, C=6^0/93 and B can be selected somewhere in between, such as 12/31/92. Generally. A is defined t>ased 
on the data extraction protocol (i.e., from when the dafa is available) and C Is defined by the last day tor which the mem- 
ber is still enrolled and eligible for the benefits. Of course, variations of those general points of definition could be 
selected within the scope of the present invention. 

[0100] The definition of the present instant B is important. In the subject invention, two basic drfinitions of B were 
devised in order to maximize the accuracy of the prediction nKXfel. Although, as would be understood by those skills 
in the art, alternative definitions of B may also be used. 

[0101] Figure 10A illustrates an exemplary time window scheme, referred to as Scheme 1, for use in processing the 
data from the event level files shown In Figure 6. 

[0102] In Scheme 1 . the event prediction region is set from B to C such that B=C-(x# of months) for all the membere 
in the analysis. For example, if a 6-month CHF hospitalization (HL) model (i.e. HL is used as a dependent variable) is 
to be built then B=C-(6 months) . In Jane Doe's example. B would equal 12/31/92. Therefore, only data covering from 
A through B (1/1/91-12/31^) is used to predict the CHF in the 'next 6 months'. The phrase 'next 6 months' in this con- 
text implies that the time point B is "NOW" and any time after rl is in the FUTURE and any time before it is in the PAST 
This is a key concept of Scheme 1 and is important to understanding the prediction nrodel implementation and applica- 
tion. 

[01 03] In alternative embodimente, analysis weights which reflect proximity to the event to be predicted can be used, 
for example, within 3 nnontiis x 1. 3-6 months x .75. 6-9 months x. .5.9-12 months x .25, greater ttian 12 morths x .125. 
Other suitable weighting techniques, as will be appreciated by ttiose skilled in the art. such as negative weights could 
also be used. For example, in the exemplary embodiment of ttie present invention, the actual weighting factor us&i is 
Ue'^ where x = time in months from point B for each event. 

[0104] Therefore, given a selected time window scheme and an appropriate set of predetermined variables, the 
processing step of 650 gen^ates ttie analysis file. 

[0105] Returning to Rgure 6, once the /Analysis files are generated in step 650. the next step, step 660. is to Process 
Analysis File Using Statistical Data, step 660. which provides ttie Identified Disease Prediction Model. 
[0106] Using the analysis file, the model for identiflcation/iprediction can then be dev^oped in various ways using sta- 
tistical techniques. In particular, the analysis file, now at a member level, is processed using statistical functions avail- 
able in SAS. In the exenplary embodiment of the present invention, the statistical processing performed to geierate the 
prediction model is multiple logistic regression. As will be appreciated by those skilled in tiie art, other statistical tech- 
niques may also be suitable for use witii the present invention. 

[0107] In tiie exemplary embodiment, the statistical processing, when applied to the analysis file, identifies variables 
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which meet predetermined levels of significance (e.g., probability value < 0.05). These variables then fonn a prediction 
model which is a mathematical equation of the following form: 

Logit(p) = a -0- bx ^ -i-cx2...+ zx, 

where x1...xi are the tdentifi^ variables and a...z are there parameter estimates. An individuaPs probability (p) 
for the outcome under consideration is then determined using the following formula: 

p^g-logrt(p)^j^^g-logit(p)j 

[01 C»] Using the above steps, several experiments were conducted. In one experiment, the results for a model based 
on Scheme 1 with all commercial members and using the HL indicator as a dependent variable were determined. The 
resulting independent variables, most likely to predict an adverse CHF health outcome, were 1) ho^italization for CHF. 

2) loop diuretics - days supply. 3) hospitalization for hypertension -length of stay, 4) doctor visits for CHF. 5) doctor visits 
for Ml, and 6) ACE inhibitor possession (negative indicator). 

[01 09] In another experiment, the results for a model based on Scheme 1 with all commercial members with no prior 
CHF hospitalization and using the HL indicator as a dependent variatrfe were determined. The resulting independent 
variatrfes, most likely to predict an adverse health outcome, were 1) loop diuretics - days supply, 2) doctor visit for CHF, 

3) hospitalization for IHD, 4) doctor visit for IHD. 5) emergency room visit for diabetes. 6) hospitalization for hypertension 
- length of stay. 7) emergency room visit for lifestyle. 8) hospitalization for other heart diseases, 9) doctor visit for pul- 
monary conditions, 10) doctor visit for anemia/emergency room visit for anemia, and 1 1) prescription (Rx) for "other" 
CV drugs. 

[0110] In still another experiment, the results for a model based on Scheme 1 with Medicaid members and using the 
HL indicator as a dependent variable were determined. The resulting independent variables, most likely to predkrt an 
adverse health outcome, were 1) hospitalization for CHF, 2) loop diuretics - days supply. 3) doctor visits for CHF, and 4) 
emergency room visit for diabetes. 

[01 1 1 ] An alternative to Scheme 1 , and referred to as Scheme 2. is illustrated in Figure 1 0B which shows a second 
exemplary time window schema for use in processing the data from the event level files generated in the present inven- 
tion. 

[0112] A difference t>etween Scheme 1 and Scheme 2 Is the definition of the prediction region for mernbers which 
have at least one kJentified disease hospitalization or emergency room visit (HL/ER). The prediction region starting at 
point B. in Scheme 2. is defined in multiple passes over each member's record. Turning again to Jane Doe's analysis 
record (from 1/1/91 through 6/30/93. /U1/1/91. C=6^0/93) to illusfrate how this aspect works for defining point B. 
assume that Jane Doe was hospitalized for depression three times: on 4/1/91 , 4/1/92, and 4/1/93. 
[01 1 3] Point B Is set equal to the date of ttie first identified disease HL/ER - 1 nranth or set equal to point C if a member 
never had the identified disease HUER in their claims history. For Jane Doe, 8=4/1/91 . In the exemplary embodiment 
of the present invention, moving back one month from the HL date is performed to simulate the model application envi- 
ronment. There would probably be at least 30<lay lag from nrtodel scoring to tiie disease management actions t>as6d 
on the scoring reports. Thus, in Jane Doe's record B=4/1/91-(1 nrwnth)=2^8/91. Jane's record, in this case, would not 
be used in the model building because the time span of the analysis region is only two months-less than the exemplary 
six month data history requirement. 

[0114] Repeating steps 1 and 2 using second (or third or...) HLdate to set point B, Jane Doe's record would eventually 
make it into modd building on the second and third pass. This process, in the exemplary embodiment, terminates after 
three or four passes since there would probably be very few members witii five or nrore identified disease HL/ERs in 
the study population. 

[01 15] It shoutd b>e noted tfiat tiie consequence of repeated modeling introduces added complexfty of setting up ^i- 
tional independent variables. An important advantage, however, of Scheme 2 is that the prediction HITER rate would 
likely be higher than in Scheme 1 . 

[0116] In still anottier alternative embodiment, analysis weights which reflect proximity to the event to be predicted 
can be used, for example, within 3 nranths x 1 , 3-6 months x .75. 6-9 montiis x. .5, 9-12 noonths x .25, greater tiian 12 
months x .125. Other suitable weighting techniques, as will be appreciated by those skills in the art. could be used. 
These type of weighting techniques may be used with eith^ Scheme 1 or Scheme 2. 

[0117] It should be noted that each of the experimental results indicate a different number of ind^ndent variables 
ariB used for the specific prediction models; and, depending on the precision of the nruxlels desired, more or fewer inde- 
pendent variables may be used based on their individual ability to accurately predict the selected d^endent variable. 
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Risk Stratification and Generation olf Intervention Lists 

[0118] Next, the determine prediction model Is applied to the client specified data. TTie determined model can be 
applied to the existing data, to the data as it is regularly updated or to other claims databases for other benefits provid- 
ers. To do so, only the determined independent variables of interest need to be processed. Of course, as new claims 
databases are to be analyzed, the entire process can be repeated to generate a new model in order to determine if 
other variables may be better predictors. 

[01 1 9] The output generated by applying the model is a file containing a list of all of the patients having the tdentrf led 
disease ord&'ed by an indicator representative of the likelihood that that patient will have an adverse health outcome 
(i.e., experience that is defineJ by the dependent variable). This list can then be divided, for example, into subgroups 
such as in S% or 10% inaements of patients likely to have the adverse healtti outcome. 

[0120] Mode! performance can now be assessed by determining the number of actual adverse heafth outcomes 
occurring in the prediction window for each 5% or 1 0% subgroup. 

[0121] Applying the model to futore claims data or other databases of identified disease patients or building a new 
PTKxiel in a new database as descrbed above, patients with an Identified disease at high risk can be identified allowing 
for various types of Intervention to maximize tiie effective allocation of health care resources for these patients. The 
Risk Stratification (RS) process 140 is required to geierate such lists of patients, and ttie Inten/ention Management 
process 160 receives these lists and initiates Interventions witti the patients with the identified disease. These proc- 
esses are desaibed in nrrare detail below. Such Interventions may take the form of 1) specific case management, 2) 
novel interventions based on subgroup characteristics, 3) high risk intervention, 4) high (relative) cost intervention, or 
5) plan modification all adhering, of course, to the best practice guidelines. 

[0122] Referring to Figure 1B. the Risk Stratificatiwi (RS) process 140 is required to support the Disease Manage- 
ment system by providing the Intervention Management process 1 60 with a list of patients who are at-risk of an adverse 
health outcome for an identified disease. This list of patients is called the Intervention List. 

[0123] Figure 11 shows a high level flowchart showing the Risk Stratification process 140 Including a RS Front End 
(FE) 1110 module, a RS Mining Engine (ME) 1112 module, and a RS Datatese 1118. These two modules collaborate 
to produce intervention lists from the RS Database 1118. 

[0124] The RS Front End (FE) 1110 allows end users to enter all of the information necessary to maintain and run 
disease programs for clients. 

[0125] The RS FE 1 1 10 of the present invention is written using Delphi 2.0, which is a 32 bit software development 
tod. The RS FE 1 1 10 stores cll«Tt and disease parameters in Sybase System 1 1 running on a Windows NT or UNIX 
based server. The RS FE 1 110 uses the Borland 32 Bit Sybase SQL Links database drivers. However, it is contem- 
plated that tiie present invention can be practiced using any similar development and database tools and is not limited 
to tills configuration. 

[0126] The RS Mining Engine (ME) 1112 runs ttie scheduled client identified disease programs yielding intervention 
lists that are provided to tfie Intervention Management process 1 60 of Rgure 1 B. The RS ME 1 1 1 2 is a batch/daemon 
process and follows this basic program logic: 

A. Run nightiy (batch) or as a daemon process 

B. Determine what client kJentif led disease programs need to run based on schedule and available data 

C. For every scheduled client disease program: 

a) Get disease program rule components. 

b) Get disease program parameters for each rule contponent. 

c) Validate tiiat ttie necessary data sti-eams (R^. M^ and Lab) exist for ttie idenlif led disease program 

d) initialize the scheduled client identified disease program 

e) Execute the scheduled client identified disease program 

f) Provide inten^ention lists to the Intervention Management process 160 

D. Terminate (batch) or set process to sleep (daemon) 

[0127] The RS ME 1 1 12 Is written using Delphi 2.0. which is a 32 bit software development tool. The RS ME 1 1 12 
processes disease parameters provided by the RS FE 1 1 10 combined witti client pharmacy claims, m^ical clainre and 
laljoratory test Information for specific disease programs producing spedffic intervention lists ail of which are retrieved 
from or stored in a relational database. The RS ME 1 1 12 utilizes the Sybase System 1 1 database running on a Win- 
dows NT or UNIX t>ased sender. The RS ME uses ttie Borland 32 Bit Sybase SQL Links database drivers. However, it 
is contemplated ttiat tiie present Invention can be practiced using any similar development and database tools and is 
not limited to this configuration. 
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[0128] The operation of the Risk Stratification process of Figure 1 1 is now described. End users, which may either be 
coupled to the Case Management process 150 of Figure 1 B or another separate entity, provide end user identified dis- 
ease program information to the RS FE 111 0. The RS FE records Information for the setup of new identified diseases, 
new disease programs, predictive models and rules, client specific parameters, disease specific rule parameters, and 
5 new clients; and the RS FE 1 1 10 associates disease programs with clients, schedules disease programs, and runs 
informational reports. The RS FE 11 10 records this information as a "disease program" in a format for use by the RS 
ME 1112. 

[01 29] The disease program is provided by ttie RS FE 1 1 1 0 to the RS database 1 1 1 8, and the RS database 1118 
also receives predictive model and rule information from the Predictive Modeling process 130. Rnally, the Disease Man- 
10 agement database 120 provides pati^ medical infornriation to tfie RS database 1 1 18 for the RS ME 1 1 12 when ttie 
RS ME 1112 applies the precfictive model to the patient data. Finally, the RS ME 1112 receives ttie Information con- 
tained in the RS Database 1 1 18 as tiie RS ME executes the disease program data and applies tiie predictive modd to 
the patient data. 

[0130] ngure 12 is a high level flowchart showing the RS ME 1 1 12 of the Risk Stratification process of the present 
IS invention. The RS ME 1 1 12. as shown in Figure 1 2. is composed of three major sub-systems: a RS Schedule Manager 
(SM) 1210, a RS Rule Manager (RM) 1214 and a RS Intervention Ust Manager (ILM) 1216. Each of the three sub-sys- 
tems Interacts with the RS Da1at>ase 1118, which can be a subset of the Disease Management datat>ase 1 20 of Figure 
IB, containing client and identifi^ disease program analytic configurations. 

[0131] The Disease Management database 120 is regularly updated with patient information (Member, Eligibility. 

20 Pharmacy (RJ Claims. Medical (MJ Claims and Clinical Laboratory (Lab) Claims) for each client. Consequently, the 
RS Database 1 1 18 is also updated regularly witti client and client member information. The RS ME 1 1 1 2 gathers rele- 
vant client patient information from the Disease Management Database 120 to be processed by ttie disease program 
analytic rules. In the exemplary embodiment of the invention, all relational databases are SYBASE System 1 1 . 
[0132] The RS SM 1210 compiles a list of klentified disease programs to execute by examining each enrolled client 

25 to see if the schedule time has arrived for the program to execute. Additionally, client disease programs must be 
approved for execution by the RS ME 1 1 1 2 before they may be scheduled. Approval indicates ttiat all client disease pro- 
gram parameters are entered and that the data entered has been validated by the RS FE 1 1 10 and is ready to be proc- 
essed in the RS ME 1 1 12. Finally, tiie RS SM 1210 verifies tiiat all required data streams are available. The RS ME 
1112 may be a batch program that Is executed periodically. For each identified disease program which is selected by 

30 the above logic, an RS RM object is created. RS RM objects are executed sequentially. 

[0133] The RS RM 1216 then assembles ttie rules required to implement ttie specific identified disease program into 
an ordered sequence. These rules are described in detail subsequently, and are provided by the Predictive Modeling 
process 130 and the Case Manager 150. Each rule object is initialized witti disease program and client specific rule 
arguments. Rules sequences desirat>ly contain one or more Common rules and one or more sequence of rules called 

35 Patient Group Classifiers (PGCs). PGCs are used to stratify a targetwJ client patient population into specific groups for 
intervention or reporting based on ^ecif ic criteria. All interventfons and reporting is performed based on patient mem- 
bership in one or nnore of the disease program PGCs. 

[01 34] Comrrran rules are executed in ttie specified order prior to any PGCs. In general, rules are designated as com- 
mon rules because they eittier prepare the environment for other rules (Client Participation. R^ Claims, M^ Claims, etc.) 
40 or they perform exclusions ttiat reduce the overall patient set size prior to being acted upon by ottier complex rules 
(Patient Active. Patient Age, Patient Gender, etc.). ttius improving overall performance. Patients who 'fail' ttie specified 
rules are removed from ttie patient set. 

[0135] PGCs are executed in parallel with ttie rules in each PGC also being executed in parallel on the patient set 
provided by ttie common rules. PGC rules use a tally mechanism for each patient in ttie set to indicate passage or fail- 

45 ure of the specified rule for that patient. 

[01 36] Upon completion of all PGCs the RS ILM 1 21 6 scores each patient for membership in each PGC. The RS ILM 
1216 then generates and stores intervention lists for later processing by the Inten/ention Management process 160. 
[01 37] The RS SM 1 21 0 initially queries ttie RS Database 1 1 1 8 at startup of batch process or periodically if mnning 
as a daemon to determine if the approved client identified disease programs scheduled run date has arrived and if all 

50 required client data streams are up to date. If all required data streams are available, a Rule Manager (RM) object is 
created for each client disease program. 

[01 38] Identified disease program attributes are stored in a table. One attribute is the approval status. Each identified 
disease program is desirably approved before it is scheduled. If any identified disease programs are scheduled, ttien 
the disease program approval may not be revoked. 
55 [01 39] Determining which programs require execution and when is accomplished via a schedule taWe which contains, 
among other things, a status and a scheduled run date. Once the scheduled date is reached tiie program is executed 
and the status is updated to running. 

[0140] The RS RM 1214 is responsible for running and managing the results of a single disease program. 
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[0141 ] The rules are grouped according the Patient Group Classifier (PGC) that they are assigned to. First all the com- 
mon rules (those without a PGC) are run. Then the rules for each PGC which exists in the disease program are run 
[0142] The RS ILM 1216 evaluates each client disease program tfrat successfully executed and contpiles a listing in 
a intervention candidates table of the members selected by the program as belonging to each PGC within that program. 
[0143] A member is included in a PGC if the member has not been dieted from the set by any comnran rule, and the 
member's output for each PGC rule matches the desired value (1 for non-negated rules and null for negated rules). 
[0144] Members who are included in a PGC are populated into an interventions table, which can also be the int^en- 
tion list. This table includes identifying information for the member selected, the program run, the PGC in which the 
member was included, and the ph^idan which was identified if the Physician Identification Rule was used. 

Rules - General Classif ccation 

[0145] A rule classified as a "Root Rule" indicates that the rule is required to run before all otiiers and performs certain 
environment initializations for all other rules. Every identified disease program must have one and only one root rule. 
Currentiy, the only root rule is Client Participation. 

[0146] A rule classified as a "Common Rule" indicates that the rule is eligible to be executed prior to any PGC. Mem- 
bers who fail' comnrv)n mles are remove from the patient set. A rule can be simultaneously eligible to be executed as 
a common rule artd a PGC rule. 

[0147] A rule classified as a "PGC Rule" indicates that the rule is eligible to be executed after common rules in parallel. 
Members who 'pass' PGC rules are marked in a column specifically added for that mle in a tabla A rule can be simul- 
taneously eligible to be executed as a common rule and a PGC rule. 

[0148] The rule "Creates Pharmacy Claims" creates a table for pharmacy claims. Every identified cfisease program 
that uses pharmacy claims for a data source desirably has a rule that performs this function prior to rules tiiat use phar- 
macy claims. 

[0149] The rule "Creates Malical Claims" creates a table for medical claims. Every identifi«J disease program that 

uses medical claims desirat>ly has a rule that performs this function prbr to rules that use medical claims. 

[0150] The rule "Creates Clinical Test Data" creates a table for clinical test data. Every disease program that uses 

laboratory claims desirat>ly has a rule that performs ttiis function prior to rules that use laboratory claims. 

[01 51 ] The rule "Uses Specialties" uses physician specialty information. 

[0152] The rule "Uses Pharmacy Oaims" uses the table containing pharmacy claims information. 

[0153] The rule "Uses Medical Claims" uses the table containing medical claims information. 

[0154] The rule "Uses Clinical Test Data" uses tiie table containing clinical test infomnation. 

[0155] All the mle objects in ttie RS ME 1112 are descend^ from a common ancestor which provides some basic 

functional structure shared by all rules 

Rules Selection Rules and intervention Rules 

[0156] The present embodiment of the RS ME 1 1 12 supports various selection and intervention rules: 

1) Client Participation Rule 

Identifies whetiier a patient is part of a group that has been enrolled into the disease management program. 
This rule will ensure that all patients considered by ttie following rules are part of a group that the client wishes to 
have participate in the program. This rule may also validate that the patient has the proper benefit structure to per- 
mit the disease program to function. Client Participation is currently the only root rule. It is desirat>ly. therefore, the 
first rule in every disease program. It is always executed as a common rule. 

2) Rx Claim Rule 

This rule selects all pharmacy claims data that is applicable to the execution of a single identified disease pro- 
gram. It identifies all pharmacy prescription claims sheeted for a specific drug group witiiin a ^ecif i^ analytic time 
frame. The R^ Claim rule is always a comnrton rule. It is typically only run once in a given program. 

3) Existence of a Specific Drug Rule 

This rule identifies members with at least one claim for a drug in the specified drug group within the rule time 
frame. This rule may be run as either a common or a PGC rule. 

4) Recurrent Patient Rule 

This rule identifies whether a patient has a pattern of drug use which indicates the potential of multiple inde- 
pend»rt episodes (recunrence) of a disease. The rule will select patients with at least a certain number of discrete 
episodes of a particular drug therapy. This rule may be run as eittier a common or a PGC rule. 

5) Stoppage in Current Therapy Rule 

This rule identifies patients whose drug therapy for a particular drug group has been stopped. This is deter- 
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mined based on the last prescription for a drug in that drug group. This rule may be run as either a common or a 
PCG rule. 

6) Patient Age Rule 

This rule identifies patients whose ages fall within a specified target range. This rule may be run as either a 
5 comrTK>n or a PGC rule. 

7) Minimum Patient Eligibility Rule 

This rule identifies whether a patient is eligible for medical and/or drug benefits for a specified continuous 
period of time. This rule may be run as either a common or a PGC rule. 

8) Patient Active Rule 

^0 This rule verifies that a member is active and in a group which is included in the program at the time of inters 

vention. This rule may be run as either a common or a PGC rule. 

9) Average Puff Equivalence Rule 

This rule identifies whether a member has the required average puff equivalence of drug therapy during a 
specified time frame. This rule may be run as either a common or a PGC rule. 
15 1 0) Count of Occurrences Rule 

This rule identifies whether a patient has a selected range of occun-ences on different filled dates for a speci- 
fied drug therapy. This rule may be run as either a comnwn or a PGC rule. 
11) Patient Gender Rule 

This rule identifies members of a particular gender. This rule may be run as either a common or a PGC rule. 
20 1 2) Dose Level Recurrence Rule 

This rule identifies whether a patient has a pattern of drug use within a specified dose range which indicates 
the potential of nrultiple independent episodes (recurrence) of the disease at the same or similar severity. This rule 
may be run as either a common or a PGC rule. 

13) Continuous Therapy at Required Dose Level Rule 

25 This rules identifies patients who have continuous drug therapy within a specific dose range for a specified 

length of time. This rule may be run as either a common or a PGC rule. 

14) Concurrent Therapy Rule 

This rule identifies patients who have overlapping therapy of at least a given duration for the specified drug 
groups. This rule may be run as either a comnrwn or a PGC rule. 
30 15) Dose Level Rule 

This rule identifies patients who have Rx Claims for a specified drug therapy within a specified dose level range. 
This rule may be run as either a common or a PGC rule. 

16) Drug Usage Level Rule 

This rule identifies members whose drug usage relative to expected values is within a specified range. Typi- 
35 cally, this rule will be used to determine members who are non-compliant with a specified drug therapy. This rule 
may be run as either a common or a PGC rule. 

17) Weighted Existence of Specific Drug Rule 

This rule identifies members whose drug therapies fall within a designated risk score range. Each drug therapy 
is assigned a risk score and a member's drug history is assessed to determine his/her accumulated risk score. This 
40 rule may be run as either a common or a PGC rule. 

18) Physician Identification Rule 

This rule selects the specific Prescriber to send communication regarding a member who has been identified 
for intervention. This selection is based on the Pharmacy Claim data for that member and/or information about the 
member's primary care physician which may be found in the Member data in the Patient Data Repository 120. This 
45 rule may be run as either a common or a PGC rule. 

19) All Member Rule 

The All Member Rule selects all members present in the record set. This is used to support a PGC which con- 
tains all members selected by the common rules. This rule may also be used internally by tiie RS ME 11 1 2 in order 
to sijpport certain types of disease program optimization. This rule may only be used as a PGC rule. 

so 

[0157] Appendix VI includes a list and description of the selection rules as used in one entxxliment of ttie invention. 
It should be apparent to tiiose skilled in the art tiiat these rules can t>e nxxlif ied or deleted, and new rules created for a 
particular embodiment of the invention. 

55 Intervention Management Process 

[01 58] Once again referring to Rgure 1 B, the Risk Stratification process 1 40 outputs the Intervention List to ttie Inter- 
vention Management process 160 to initiate specific interventions. Interventions may include initial offerings, fully 



20 



EP 0 917 078 A1 



administered disease programs, forwarding educational materials, intx>und or outbound telecommunications, faxes, 
Email or Voice Response interactions virith member patients identified on the Intervention list. The Intervention Manage- 
ment process 160 provides the intervention information to the Intervention Records and Tracking process 170, which 
records the interventions to determine if proactive disease management services improve specific disease outcomes. 

5 [0159] Rgure 13 Is a high level diagram of the Intervention Management process 160 of the present invention, and 
the intervention process, called an intervention program, is performed on an intervention list of client members having 
an Identified disease. The Intervention Management process 160 shown in Rgure 13 includes Program Initiation 1310» 
which starts the intervention program; Enrollment 1320, which enrolls identified patients into the intervention program; 
Inten^ention 1330, which initiates the intervention with the enrolled patient; and Analysis 1340, which analyzes the 

10 results of an intervention with a patient. 

[0160] The Inten^ention Management process 160 is provided data by the Disease Management database 120 as 
well as the intervention list from the Risk Stratification process 1 40. Tliis data feed or detection process has parameters 
that identify a specific patient meeting the conditions for participating in a disease program. This detection process pro- 
vides a population for consideratk>n in the specific disease program under tiie following conditions: 

IS 

1) The Disease Management database 120 provides client's updated identified disease patient data to the inter- 
vention management system on a scheduled basis. 

2) The Intervention Recording and Tracking process 170 passes intervention contact data back to the Disease 
Management database 120. This intervention data is stored there for use in the analytic process. 

20 3) The Intervention Management process 160 detects, selects and passes new intervention data on "adds" which 
are defined as new enrollees, changes in disease detection. sut>sequent diagnosis or an individual enrollment 
request from an intervention manager. 

4) The Intervention Recording and Tracking Process 170 revises patient data on those individuals prewously 
selected for tiie program. Data revisions occur when personal or medical data changes. For example, additional 
25 medical or pharmacy claims are received or additional laboratory reports are secured. 

[01 61 ] Referring to Rgure 1 3. ttie f irsl step of tiie process is program initiation, step 1310. Program Initiation is a proc- 
ess where a disease program is initiated through the process of selection of a population of patients based on prede- 
fined criteria and tiie initial interventions are sent Upon selection specific predefined program activities take place. 
30 [0162] A sample initiation might be tiiat 1) a letter is sent, on behalf of the patient, to their physician informing tfiem 
of this patient's identification into the program, the disease protocols and the recommerxied actions from the physrcian. 
2) Intervention Management data is passed from the Disease Management database 1 20 to the Interventbn Manage- 
ment system 160 and is loaded. 3) An initial "contact segment" is added for the patient indicating the sending of tiie phy- 
sician letter. 

35 [0163] Another sample initiation might be: 1) a letter is sent to tiie patient, witii a copy to their physician informing 
them of their inclusion in the disease program. 2) The patient may be requested to call into a Voice Response System 
to anwer specific questions. 3) The contact is added and the responses analyzed for further processing. 
[0164] The second step of tiie process is tiie Enrollment step 1320. In tiiis step the Patients are enrolled into tiie pro- 
gram. Patients are enrolled into the Disease Management service ttirough interfaces to the Intervention Management 

40 System. These interfaces can be through a Voice Response System, written letter retijrn or a direct call. The enrollment 
process triggers the scheduling of an intervention event within the intervention management system. 
[01 65] The next step is the Intervention process 1 330. which is tiie process of interceding witti a physician and dient 
for the purposes of: 1) ensuring compliance with a course of ti'eatinent. 2) providing disease educational material to 
botii the patient and physician, 3) providing emergency assistance from a distance, 3) bgging each and every interven- 

45 tion as a "contact" to provide assistance in determining program effectiveness and to estat>lish a framework to make 
mid-course adjustments to tiie program, and 4) providing data back to tiie product managers on program effectiveness. 
[01 66] The last step is the analytic process 1 340 whrch assimilates disease information for tiie purposes of determin- 
ing disease management service success. Although the intervention management system does not produce the ana- 
lytic reporting, critical information is passed back during tills process to tiie Disease Management Database 120 for 

50 processing. 

[0167] While the invention has been described in terms of an exemplary embodiment, it is contemplated that it may 
be practiced as outlined above witii nxxfrf ications tiiat are within the scope of the following daims. 

Claims 

55 

1. A computer-implemented method for disease or condition intervention management using information atx)ut 
patients existing in at least one database, said mettiod comprising tiie steps of: 
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a) processing, based on predetermined criteria, the patient initormation in the database to extract patient infor- 
mation for a group of patients relating to an identified disease or condition; 

b) defining a predictive model, including: 

0 defining, using the information available in tiie database, a set of events or data relevant to the identified 
disease or condition; 

ii) converting the extracted patient information and the defined events or data into files comprising event- 
level information; 

iii) defining a time-window for providing a timeframe from which to judge whether specific ones of the 
defined events should be considered In subsequent processing; 

iv) identifying a set of variables as potential predictors; 

v) processing the event-level information, using the time-window and tiie set of variables, to generate an 
analysis file; 

vi) performing statistical analysis on the analyst file to generate the prediction model and a set of rules for 
use in identifying at-risk patients diagnosed^with or who may develop the identified disease or condition, 
said prediction model and rules being a function of a subset of the set of variables; 

c) applying the prediction nrxxJel and the rules to the sanre or new set of event-level information to identify at- 
risk patients for tiie identified disease or conditfon, or to identify patients who may be at risk for developing tiie 
identified disease or condition; 

d) preparing an intervention list from the identified at-risk patients and selecting, for at least one at risk patient, 
an intervention; 

e) distributing or facilitating the cfistribution of the intervention to said patient: and optionally 

f) recording and t-acking an intervention result for each at-risk patient based on the respective selected inter- 
vention: and optionally 

g) updating ttie historical data in at least one database with each intervention result corresponding to said data- 
base; and 

h) repeating step b(ii); and 

I) re-applying the prediction model and rules to the event-level information extracted from the data in the 
updated database. 

A computer-implemented system for disease management using information atx)ut patients existing in a datat>ase. 
said system conrprlsing: 

a) processing means for processing, based on predetermined criteria, the patient information in the database 
to extract patient information for a group of patients having an identified disease or condition; 

b) means for defining a predictive nrxxtel, including: 

i) event definition means for defining, using tiie information available in the database, a set of events rele- 
vant to the identified disease or condition; 

ii) conversion means for converting the extracted patient information and the defined events into files con- 
taining event-level information; 

iii) means for defining a time window for providing a timeframe from which to judge whether specific ones 
of the defined events should be considered in subsequent processing; 

iv) means d^ining a set of variables as potential predictors; 

v) means for processing the event-level information, using the time window and the set of variables, to gen- 
erate an analysis file; 

vi) means for performing statistical analysis on the analysis file to generate the prediction model and a set 
of rules for use in identifying at-risk patients diagnosed with the identified disease, said prediction model 
and rules being a function of a subset of tiie set of variat)les; 

c) means for applying tiie prediction model and the rules to tiie same or new set of event-level Information to 
identify at-risk patients for the identified disease or condition; 

d) means for forming an intervention list from the identified at-risk patients and selecting, for at least one at risk 
patient, an intervention; 

e) means for distributing or facilitating the distribution of tiie intervention to said patient; and optionally 

f) means for recording and tracking an intervention result for each at-risk patient based on the respective 
selected intervention; and 
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g) means for updating the historical data in at least one database with each intervention result corresponding 
to said datak>ase or creating a mirror database using the data obtained in step f); and 

h) means for repeating step b(i); and 

1) means for re-applying the prediction model and rules to the e^ent-level information extracted from the data 
in the updated database. 

A process for preparing a health intervention product from patient information in a conputer database said process 
corrprising: 

a) using a computer for extracting and processing, based on predetermined criteria, the patient information in 
the dalat^ase to ot>tain a data file of patient inforn^tion for a group of patients having an identified disease or 
condition; 

b) programming a predictive model into a computer wherein the nxxiel constructed includes tiie steps of: 

1) defining, using the information available in the database, a set of events relevant to ttie identified disease 
or condrtfon; 

ii) converting tiie extracted patient information and the defined events into files containing event-level infor- 
mation; 

iiO applying a time window for providing a timeframe from which to judge whether specrfic ones of the 
defined events should be considered in sut>sequent processing; 

iv) entering a set of variables as potential predictors; 

v) generating an analysis file by processing ttie event-level informatfon, using the time window and the set 
of variables; 

vi) performing statistical analysis on tiie analysis file to generate the prediction nrxxiel and a set of rules for 
use in identifying at-risk patients diagnosed with the identified disease or condition, said prediction nxxiel 
and rules being a functfon of a subset of tiie set of variables; ttien 

on a conrputer: 

c) running tiie prediction nxxJel and ttie rules against ttie same or new set of event-level information to Identify 
at-risk patients for ttie identified disease or condition; 

d) outputting an intervention list from the identified at-risk patients and selecting, for at least one at risk patient, 
an intervention; 

e) distributing the intervention to said patient; and optionally 

f) recording and tracking an inten^ention result for each at-risk patient based on ttie respective selected inter- 
vention; and 

g) updating ttie historical data In at least one database or creating a new database witti each interventfon result 
con-esponding to said database; and 

h) re-runriing step b(i); and 

i) re-running the prediction model and rules against the event-level information extracted from the data in the 
database created in step g; and optionally 

j) outputting an intervention list obtained by re-running the prediction nrxxlel and the rules against the database 
created in step g. 

A heafth intervention product made by the process of: 

a) using a computer for extracting and processing, based on predetermined criteria, the patient information in 
ttie database to obtain a data file of patient information for a group of patients having an identified disease or 
condition; 

b) programming a predictive nxxJel into a computer wherein ttie nxxjel constructed includes ttie steps of: 

i) defining, using the information availat3le in the datat}ase, a set of events relevant to the klentif led disease 
or condition; 

ii) converting tiie extracted patient information and tiie defined events into files containing event-level infor- 
mation; 

lii) applying a time window for providing a timeframe from which to judge whether specifk; ones of ttie 
defined events should be considered in sut>sec|uent processing; 

iv) entering a set of variables as potential predictors; 

v) generating an analysis file by processing ttie event-level infomnation. using tiie time window and the set 
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of variables; 

vi) performing statistical analysis on the analysis file to generate the prediction model and a set of rules for 
use in identifying at-risk patients diagnosed with the identified disease or condition, said prediction nrxxlel 
and rules being a function of a subset of tiie set of variables; then 
on a computer: 



c) running the prediction nrKxjel and the rules against the same or new set of event-level information to identify 
at-risk patients for the identified disease or condition; 

d) outputting in hard copy or nwchine-readaWe form an intervention list from the identified at-risk patients and 
selecting, for at least one at risk patient, an intervention; 

e) distrbuting the intervention to said patient; and optionally 

f) recording and tracking an intervention result for each at-risk patient based on ti^e respective selected inter- 
vention; and 

g) updating the historical data in at least one database or creating a new database witii each intervention result 
corresponding to said datat}ase; and 

h) re-running step b(i); and 

i) re-running ttie prediction nxxiel and rules against the event-level information extracted from the data in the 
datat)ase created in step g; and optionally 

J*) outputting an intervention list obtained by re-running the prediction model and tiie rules against tiie database 
created in step g. 
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